Client/Matter: 40101/00702 



U.S. Patent Application 

For 

SYSTEM AND METHOD TO STORE DATA 
IN THE SYSTEM MEMORY OF A 
COMPUTING DEVICE 



Inventor(s): 
Kadir OZDEMER 
Shankar JAYARAMAN 



Total pages: 21 



Prepared by: 

Fay Kaplun & Margin, LLP 

150 Broadway, Suite 702 
New York, NY 10038 
(212)619-6000 



Express Mail Certificate 7 ' » 

"Express Mail" mailing label number EV 323 424 955 US 

Date of Deposit MAY 6. 2004 - 1 

I hereby certi fy that this correspondence is being deposited^vvith the^ 
States Postal Service "Express Mail Post Office to Addressee'%erviceundeiv3N^FR 
1 .10 on the dale indicated above and is addressed to: Gomrnissionenlbr Patents^ PiO] 
Box 1450, Alexandria. VA. 22313-1450 . ^ ' . . \ 

Nanie Michael J. Marcin. Reg. No. 48.198 ' ' | 



Signature ^ 




A SYSTEM AND METHOD FOR MANAGING THE MEMORY IN A COMPUTER SYSTEM 



Background Information 

[0001] A computer system is comprised of numerous different components, each of 

which has a particular function in the operation of the computer system. For example, Figure 1 

5 depicts an exemplary embodiment of personal computer ("PC") 1 which may be a computing 
device or other microprocessor-based device including processor 10, system memory 15, hard 
drive 20, disk drive 25, I/O devices 30, a display device 35, keyboard 40, mouse 45 and a 
connection to communication network 50 (e.g., the Internet). Each of these devices in PC 1 has 
one or more functions which allow PC 1 to operate in the manner intended by the user. For 
10 example, hard drive 20 stores data and files that the user may wish to access while operating PC 
1, disk drive 25 may allow the user to load additional data into PC 1, 170 devices 30 may include 
a video card which allows output from PC 1 to be displayed on CRT display device 35. 

[0002] System memory 15 may be, for example, Random Access Memory ("RAM") 

15 which is a type of memory for storage of data on a temporary basis. In contrast to the memory in 
hard drive 20, system memory 15 is short term memory which is essentially erased each time PC 
1 is powered off System memory 1 5 holds temporary instructions and data needed to complete 
certain tasks. This temporary holding of data allows processor 10 to access instructions and data 
stored in system memory 15 very quickly. If processor 10 were required to access hard drive 20 
20 or disk drive 25 each time it needed an instruction or data, it would significantly slow down the 
operation of PC 1. All the software currently running on PC 1 require some portion of system 
memory 15 for proper operation. For example, the operating system, currently running 
application programs and networking software may all require some portion of the memory space 
in system memory 15. Using the example of an application program, when the user of PC 1 
25 enters a command in keyboard 40 or mouse 45 to open a word processing program, this 
command is carried out by processor 10, Part of executing this command is for data and 
instructions stored in hard drive 20 for the word processing program to be loaded into system 
memory 15 which can provide data and instructions to processor 10 more quickly than hard drive 
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20 as the user continues to enter commands for the word processing program to execute. 

[0003] When system memory 15 is RAM, the memory is randomly allocated to the 

applications in small chunks as needed. The chunks allocated to individual software programs 
5 do not have to be located continuously within system memory 15. Processor 10 assigns each 
chunk a particular address and, in that way, processor 10 may randomly choose such addresses 
from a pool of available addresses. Since processor 10 continually assigns random addresses, the 
data for each individual program becomes highly fragmented throughout the memory space in 
system memory 15. This fragmentation requires processor 10 to access muhiple memory areas 
10 of system memory 15 for an individual application. This multiple accessing of system memory 
15 slows down program operation and leads to inefficiencies in the operation of PC 1. 

[0004] Additionally, when processor 10 assigns addresses to the memory chunks of 

system memory 15, these chunks are of a defined size, for example, 8 bytes. Every time a 

1 5 particular address is accessed and used to store data, the entire chunk is allocated without regard 
to the actual size of the data. For example, if processor 10 is loading data having a size of 4 
bytes into a chunk of system memory 15 which is 8 bytes, the entire 8 bytes is not available even 
though only 4 of the 8 bytes are actually being used. As more data is stored in the temporary 
memory of system memory 15, there may be a large amount of memory allocated to data that is 

20 not actually being used, but yet it cannot be allocated for other data because processor 10 detects 
that the address for the space is in use. Similarly, if processor 10 is loading data that is larger 
than the pre-assigned defined size of the chunks, chunks must be coalesced into a chunk large 
enough to handle the information. 

25 

Summary of the Invention 

[0005] A method for managing a memory of a computer system to store data of a 
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particular size by defining chunks of the memory, wherein each chunk is a continuous memory 
space of a predetermined size. Defining chunk pools for managing the chunks, wherein each 
chunk pool corresponds to chunks of a particular size and defining unit pools for managing units 
of the first size, wherein the chunk pool corresponding to the unit pool provides a chunk of the 
5 particular size to be separated into the units of the first size, and the data of the first size is stored 
in the units. 

Brief Description of Drawings 

10 [0006] Fig. 1 depicts a conventional computing device. 

[0007] Fig. 2 shows an exemplary computing system on which the present invention may 

be implemented. 

1 5 [0008] Fig. 3 shows an exemplary division of system memory into various size chunks 

that are grouped into chunk pools according to the present invention. 

[0009] Fig. 4 shows an exemplary relationship between units, unit pools, chunks and 

chunk pools according to the present invention. 

20 

[0010] Fig. 5 shows an exemplary process flow for implementing a memory manager 

according to the present invention. 

[001 1] Fig. 6 shows exemplary chunk pools and associated unit pools storing data as 

25 described in the exemplary process of Fig. 5 according to the present invention. 

[0012] Fig. 7 shows an exemplary process flow for allocating system memory space to 

chunks according to the present invention. 
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[0013] Fig. 8 shows an exemplary process for combining unused chunks according to the 

present invention. 

Detailed Description 

5 [0014] The present invention may be further understood v^ith reference to the following 

description and the appended drawings, wherein like elements are provided with the same 
reference numerals. Throughout this specification the term system memory will be used, and it 
should be understood that this term may refer to any type of RAM, for example, Static RAM 
C'SRAM"), Dynamic RAM ("DRAM"), Synchronous DRAM ("SDRAM"), Enhanced DRAM 

10 ("EDRAM"), etc, but also to any type of temporary memory device that stores data and/or 
instructions for use by a computing device. Additionally, throughout this specification, the 
system memory will be discussed as being accessed and allocated by a processor or 
microprocessor and it should be understood that the present invention may be implemented in 
any computing and/or electronic device where processors and/or microprocessors perform such 

15 functions, for example, PCs, servers, internet devices, embedded devices, or any computing 
device. 

[0015] Referring to Fig. 2 there is illustrated an exemplary computing system 100 on 

which the present invention may be implemented. Exemplary computing system ICQ may 

20 include, among other things, system memory 1 10, processor 120 and permanent memory storage 
130. As described above, system memory 110 may be RAM or any other type of temporary 
memory device that stores data and/or instructions. Permanent memory storage 130 may be, for 
example, a hard drive. If it were considered that computing system 100 was a typical PC and 
system memory 110 was the RAM component and permanent memory storage 130 a hard drive, 

25 there would normally be 64 or 128 Mbytes of system memory 110 and 2-20 Gbytes of memory in 
permanent memory storage 130. Of course, the goal of PC manufacturers is to continually add 
additional RAM and hard drive space in PCs and devices such as servers may have significantly 
more system memory, while embedded devices may have less system memory depending on the 
particular application. The present invention is not limited by the size of the system memory, it 
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may be more or less than the exemplary values discussed above. In a computing device, 
processor 120 would allocate system memory 1 10 as needed to run the operating system and any 
additional software, for example, application programs and networking software. This allocation 
may be accomplished by, for example, copying data needed to run the software from the 
5 permanent memory of permanent memory storage 1 30 to the temporary memory of system 
memory 110. When the data is no longer needed in system memory 1 10 to run the particular 
software, the data is erased and the memory space it occupied becomes available for processor 
120 to randomly load new data into system memory 110. Those skilled in the art will understand 
that the data may not actually be erased it may merely be flagged so it can be overwritten or a 
10 pointer may be set allowing the data to be overwritten, however, for the remainder of this 

specification erasing the data will mean any of the common methods of signaling there is free 
space in system memory to allow new data to replace data that is no longer required by the 
system. 

1 5 [0016] In an exemplary embodiment of the present invention, system memory 1 10 is not 

treated as one big chunk of memory space (e.g., 128 Mbytes) to be allocated for data at random, 
but rather is divided for more efficient use by processor 120. The division of system memory 
1 10 is based on the principle that data of the same size will be stored in the same continuos areas 

of system memory 1 10. This data will not become fragmented because as data is erased from 
20 system memory 1 10, any new data of the same size may be written into the memory space 
vacated by the erased data. 

[0017] Fig. 3 shows an exemplary division of system memory 110 into various size 

chunks that are grouped into chunk pools according to the present invention. A chunk is a 
25 continuous physical memory space of a specified size. These are the continuous memory areas 
where data of the same size may be stored. Chunks 1 5 1 -1 52 may have a size of, for example, 
512 bytes each and belong to chunk pool 150, chunks 161-162 are twice as large at 1,024 bytes 
each and belong to chunk pool 160, and likewise, in this exemplary embodiment each of the 
successive chunks in the remaining chunk pools are twice as large as the chunks in the previous 
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chunk pools. Thus, chunks 171-172 are 2,048 bytes, chunks 181-182 are 4,096 bytes and chunks 
191-192 are 8,192 bytes. All chunks are memory spaces within system memory 110 and may be 
located anywhere throughout system memory 110; the only requirement may be that the bytes in 
a particular chunk are continuous. For example, as described above, system memory 1 10 may 
5 have an overall size of 128 Mbytes which could be represented as 128,000,000 consecutive 
storage areas having 1 byte of storage. Therefore, chunk 151 having a size of 512 bytes may 
occupy any 512 bytes within the 128 Mbytes, but the 512 bytes occupied by chunk 151 should be 
continuous. Thus, chunk 151 may occupy byte locations 1-512 in system memory 110 or, just as 
likely, it may occupy locations 10,001-10,512 or any other continuous memory area of 512 bytes. 
10 Chunk pools 150-190 manage the memory chunks of a certain fixed predetermined size. For 
example, chunk pool 150 manages chunk pools 151-152 which has a size of 512 bytes. If any 
additional chunks of 512 bytes are created, such a new chunk would be managed by chunk pool 
150 because it has been defined as the manager of 512 byte chunks. The defining of chunks and 
chunk pools will be described in greater detail below. 

15 

[0018] The number of chunks and chunk pools and the sizes of each described with 

reference to Fig. 3 are only exemplary and any number of chunks and/or chunk pools of any size 
may be selected in implementing the present invention. Additionally, there is no requirement 
that each of the chunks be one half the size of the next largest chunk or that the larger chunks be 

20 some factor of the smaller chunks. However, as will be described in greater detail below, there 
may be some embodiments of the present invention which are more easily implemented when the 
larger chunks are some factor of the smaller chunks as shown in Fig. 3. It should also be noted 
that chunks 151-192 do not need to exist at the time system 100 is started. The chunks may be 
dynamically created as they are needed during runtime. This dynamic creation of chunks will be 

25 described in more detail below. 

[0019] In addition to chunks and chunk pools, an exemplary embodiment of the present 

invention also includes units and unit pools. Units are the continuous portion of memory which 
are the size of the data that each unit pool will store. As described above, data of the same size 
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will be stored in the same continues areas of system memory 110. Unit pools manage units of a 
certain fixed predetermined size. Each unit pool will only manage units of the same size. Fig. 4 
shows an exemplary relationship between units, unit pools, chunks and chunk pools according to 
the present invention. Fig 4 shows chunk pool 150 which manages chunks having sizes of 512 
bytes. At the present moment there are two 512 byte chunks 151-152 being managed by chunk 
pool 1 50. There are also two defined unit pools 200 and 210. Unit pool 200 may be assigned to 
manage units having a size of four bytes. Thus, the units of unit pool 200 may be assigned as 
the storage location for data with a size of four bytes. Unit pool 210 may be assigned to manage 
units having a size of eight bytes. Thus, the units of unit pool 210 may be assigned as the 
storage location for data with a size of eight bytes. However, unit pools 200 and 210 cannot have 
any actual units until there is a physical storage location to store the associated data. Therefore, a 
unit pools is associated with a chunk pool where the unit pool may assume control over one or 
more of the chunks controlled by the chunk pool. Once the unit pool assumes control of a chunk, 
it may separate the chunk into a number of units corresponding to the unit size for which the 
particular unit pool is responsible. Then, the unit pool has actual physical storage locations for 
the data. 

10020] Referring to Fig. 4, unit pools 200 and 210 are associated with chunk pool 150 

which is responsible for the management of 512 byte chunks, e.g., chunks 151 and 152. A single 
chunk pool may be associated with multiple unit pools. When there is a request to store a four 
byte set of data, this request goes to unit pool 200 because it is responsible for the management 
of four byte data sets. When the first request is received by unit pool 200, it must make a request 
to its associated chunk pool 150 to receive control over a chunk, for example, chunk 151 so that 
it may have a physical storage location for the four byte data set. In this example, chunk pool 
150 has relinquished control over chunk 151 to unit pool 200 which separates chunk 151 into 
four byte units 201-206. It may be calculated to show that there may be 128 units of four bytes 
within chunk 151. The four bytes of data may then be directed to one of units 201-206 of chunk 
151. For example, a first four byte data set may be stored in unit 201, while a second four byte 
data set may be stored in unit 202 and likewise until all of units 201-206 are filled with four byte 
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data sets. In this manner all the stored four byte data sets may be stored in the same continuous 
memory area (/.e., the memory area of chunk 151). 

[0021] When all units 201-206 of chunk 151 are full, there may be another chunk 

5 allocated for the storage of four byte data sets. The process for allocating a new chunk from 
chunk pool 150, when it does not have any immediately available will be described in greater 
detail below. However, this new allocation will only take place when chunk 51 is completely 
full. For example, if the first four byte data set stored in unit 201, is no longer needed by the 
software program, this data is erased from unit 201 which then becomes available for use by 
1 0 another four byte data set. In this case, when the software program needs to store another four 
byte data set, unit 201 is now available to store this new four byte data set. 

[0022] Similarly, unit pool 210 is associated with chunk pool 150. When there is a 

request to store an eight byte set of data, this request goes to unit pool 210 because it is 

1 5 responsible for the management of eight byte data sets. When the first request is received by unit 
pool 210, it must make a request to its associated chunk pool 150 to receive control over a chunk, 
for example, chunk 152 so that it may have a physical storage location for the eight byte data set. 
In this example, chunk pool 150 has relinquished control over chunk 152 to unit pool 210 which 
separates chunk 152 into eight byte units 211-216. It may be calculated to show that there may 

20 be 64 units of eight bytes within chunk 152. The eight bytes of data may then be directed to one 
of units 21 1-216 of chunk 152. Once again, in this manner all the stored eight byte data sets may 
be stored in the same continuous memory area {i.e., the memory area of chunk 152). The 
association of unit pools and chunk pools in Fig. 4 is only exemplary and the unit pools may be 
associated in any manner among the chunk pools. For example, the system designer may be 

25 aware that there will be a large quantity of eight byte data sets that will be stored, while there 
may be a very limited number of sixteen byte data sets that will need to be stored during the 
operation of the system. In this case, the system designer may associate a unit pool responsible 
for eight byte data sets to a chunk pool responsible for chunks having a size of 4,096 bytes (e.g., 
chunk pool 180 and chunks 181-182). In this case, the unit pool may have 512 units of eight 
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bytes available for the storage of eight byte data sets. In contrast, the system designer may 
associate a unit pool responsible for sixteen byte data sets with a chunk pool responsible for 

chunks having a size of 1,024 bytes (e.g., chunk pool 160 and chunks 161-162), In this case, the 
unit pool may have only 64 units of sixteen bytes available for the storage of sixteen byte data 
5 sets. 

[0023] Fig. 5 shows an exemplary process flow for implementing a memory manager 

according to the present invention. As described above with reference to Fig. 2, during the 
operation of system 100, processor 120 may desire to move data from permanent memory storage 

1 0 device 1 30 to system memory 1 1 0. The exemplary memory manager process described with 
respect to Fig. 5 is directed to the orderly storage of this data in the system memory. The 
exemplary process of Fig. 5 may be carried out by a set of instructions that are stored in, for 
example, permanent memory storage device 130 or system memory 110 and executed by, for 
example, processor 120. Those skilled in the art will understand that system 100 may include 

15 multiple other devices than those depicted in Fig. 2, and the memory manager function may be 

stored and/or executed by any of these other devices. Starting with step 305, the chunk pools and 
chunks are defined, for example, chunk pools 150-190 and chunks 151-192 described with 
reference to Fig. 3. It is not necessary to allocate the system memory space for the chunks, just to 
define the various sizes of the chunks and the chunk pools which the memory manager will 

20 support. The allocation of the memory space for the defined chunks may take place at a later 
time during system operation when the particular chunk is needed. It may also be possible to 
allocate the memory space for the chunks when the chunks are defined in step 305. In this 
exemplary embodiment of the present invention, memory space from system memory will be 
allocated for one chunk in step 310. The one chunk that will have system memory space 

25 allocated will be one of the chunks that is the largest chunk size defined in step 305. For 

example, if in step 305, chunks are defined that have the sizes of chunks 15 1-192 described with 
reference to Fig. 3, that is chunks of 512 bytes, 1,024 bytes, 2,048 bytes, 4,096 bytes and 8,192 
bytes. In this example, in step 310, one chunk of 8,192 bytes in chunk pool 190, the largest 
defined size will be allocated from system memory. The reason for initially allocating this one 
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chunk is to prevent a back and forth or "ping-pong" effect between the chunks and system 
memory. 

[0024] The process then continues to step 3 1 5 where the unit pools are defined. As 

5 described above, unit pools manage equal size units where the data of the particular size 

associated with the unit pool will be stored. For example, the unit pools defined in step 315 may 
be similar to those described with respect to Fig. 4. Included in the definition of unit pools in 
step 315 is not only the size of the units which the unit pool will manage, but also with which 
chunk pool the unit pool is associated. When step 315 is complete, system operation may 
1 0 commence because all the necessary definitions for the operation of the exemplary embodiment 
of a memory manager have been made. As described above, it is not necessary for the allocation 
of step 310 to take place prior to system operation, but it may take place during system operation, 
as will be described in greater detail below. 

1 5 [00251 The remaining steps in the exemplary process of Fig. 5 are steps that may be 

accomplished during system operation, e.g., when processor 120 desires to store data in system 
memory 110. In step 320 the size of the data to be stored is identified. Another manner of 
describing this step is to determine the data size requested by the application. Once the size of 
the data is identified in step 320, it is next determined whether that size is greater than the largest 

20 unit managed in a defined unit pool. If the largest unit defined in step 315 was 2,048 bytes and 
the size of the data was larger than 2,048 bytes, for example, 4,096 bytes, then there are no 
defined units that are large enough to store the data of that size. In this case, the process 
continues to step 330 where the data bypasses any further processing by the memory manager 
and is stored directly in system memory. This storage operation of step 330 may be by any of the 

25 known techniques of data storage in system memory. In this manner, the memory manager of the 
present invention may be implemented in conjunction with these present methods for storing data 
in system memory. It should be noted that the comparison in step 325 is between the size of the 
data to be stored and the size of the largest defined unit, not the largest defined chunk. Thus, 
there may be a chunk that is larger than the size of data to be stored, but not a unit. Carrying 
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through with the previous example, the size of the data to be stored may be 4,096 bytes, the 
largest unit may be 2,048 bytes, and the largest chunk may be 8,192 bytes. Even though there is 
a chunk larger than the data to be stored, the memory manager will still proceed to step 330 
because the comparison in step 325 is between the size of the data to be stored and the size of the 
5 largest defined unit. It should also be noted that when discussing the sizes of the units it may be 
interchangeable to use the term unit pool also, because all the units in a particular unit pool will 
have the same size. Thus, for example, the largest unit may be 2,048 bytes, but so will the largest 
unit pool be 2,048 bytes because all the 2,048 byte units are in the 2,048 unit pool. 

10 

[0026] The question may arise that if there is data to be stored in system memory that is 

4,096 bytes, then why in steps 305 and steps 315 were there not appropriate chunks and units 
defined to handle the storage of data of that size. In defining the chunks and units in steps 305 
and 315, the system designer, in very few cases, will ever know the maximum size data which 

15 will be stored in the system memory. However, the system designer may know, with a fair 

degree of accuracy, a maximum unit size that may encompass 75-85% of the data that will be 
stored in the system memory (i.e., 75-85% of the pieces of data will have a size less than or equal 
to the maximum unit size). This maximum size unit which will encompass this range of the 
stored data is system dependent and may depend on a number of factors, such as, type and 

20 number of applications, network connections and protocols, etc. If the system designer elects to 
define units and chunks that are excessively large in order to ensure that every possible piece of 
data to be stored in system memory is accommodated, it may, in fact, reduce the effectiveness of 
, this exemplary memory manager process. For example, in step 310 system memory equal to the 
size of the largest chunk has already been allocated. In most instances, the largest unit pools will 

25 be associated with the largest chunk pools. Thus, excessively large maximum unit pools may 

result in the allocation of an excessively large portion of the system memory. This large portion 
of system memory will then be unavailable for other uses. Referring back to Fig. 3, it should be 
noted that the chunks referred to are only a small portion of the overall system memory 110. If, 
for example, system memory 110 had 128 Mbytes of memory, the chunks described in Fig. 3 
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only account for 31,744 bytes of this overall system memory. System memory 1 10 may have 
large portions of its memory space allocated for other purposes, for example, operating system 
requirements, that are necessary for efficient operation of the system. System memory 1 10 is not 
confined to storing the data discussed with reference to the exemplary embodiment of the present 
5 invention, but may also be utilized to store data for a variety of other purposes. Thus, the 

exemplary embodiment of the present invention may be used to manage anywhere from a very 
large portion to a very small portion of system memory 110. 

1 0 [0027) However, in either case, the exemplary embodiment of the present invention 

should operate without infringing upon the operation of these other functions of system memory 
1 10. Selecting a maximum unit pool that accommodates 75-85% of the expected data and using 
other known techniques for storing the remaining 15-25% of the data generally accomplishes the 
balancing of these different functions of system memory 110. Those skilled in the art will 

1 5 understand that the 75-85% is not a requirement of the present invention because there may be 
circumstances where more, less, or substantially less of the expected data is covered by the 
maximum unit pool size. For example, a system designer may be having particular difficulty 
with fragmentation of very small pieces of data, (e.g., 4, 8 and 16 byte sized data). In this case, 
the system designer may implement the exemplary embodiment of the present invention with a 

20 maximum unit pool size of 16 bytes which may be, for example, 10% or less of the expected data 
because conventional techniques of system memory storage are adequate for the remainder of the 
data. Likewise, there may be other instances where operating speed is critical and little or no 
fragmentation of system memory 1 10 can be tolerated. In these instances, the maximum unit 
pool size may be defined so that it encompasses 100% or nearly 100% of the expected data. 

25 

[0028] Referring back to Fig. 5 and continuing with the exemplary process, if in step 325 

the data is not larger than the maximum unit pool size, it can be stored in a unit pool and the 
process continues to step 335 to determine which unit pool is responsible for the data. For 
example, referring back to Fig. 4, if the data were a four byte set, then unit pool 200 would be 
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responsible for the data. Once the proper unit pool has been identified in step 335, the process 
continues to step 340 to determine whether there is an available unit in the identified unit pool. 
As described previously, when the system begins operation, memory space is only allocated for a 
single chunk in step 310. Therefore, it is highly likely that there will not be any available units 
5 for the first several pieces of data because the chunks have not even been allocated to the chunk 
pools and therefore, the unit pools have not yet had a chance to request a chunk from the 
associated chunk pools. Thus, it is likely that for the first several pieces of data the process will 
continue to step 345 where the chunks will be allocated. This may be a fairly detailed process 
and an exemplary process for accomplishing this allocation of chunks will be described in more 
10 detail with reference to Fig. 7. However, for purposes of the present exemplary process, it may 
be considered that the desired result is accomplished by step 345. The process then continues to 
step 350 after step 345, or if in step 340 it is determined that there is an available unit for the 
data. In step 350, the data is stored to the appropriate unit and is available for future retrieval and 
use by, for example, processor 120 of Fig. 2. 

15 

[0029] Fig. 6 shows exemplary chunks 400-420 under the control of unit pools 430-450 

and associated units storing data as described in step 350 of the exemplary process of Fig. 5. 
Each of chunks 400, 410 and 420 have been previously defined in terms of size and terms of the 
size of the units with which they are associated as in, for example, steps 305 and 315 of Fig. 5, 

20 respectively. Chunk 400 is an exemplary 32 byte chunk which is associated with 4 byte units 
401-408. Chunk 410 is an exemplary 64 byte chunk which is associated with 8 byte units 411- 
418. Chunk 420 is an exemplary 128 byte chunk which is associated with 16 byte units 421-428. 
Four byte units 401-403 of chunk 400 already have data stored in them, thus pointer 409 is 
directing that the next piece of data that is four bytes should be stored in unit 404. For example, 

25 referring back to Fig. 5, if in step 320 it is determined that the data size is four bytes, the process 
continues to step 325 which determines that four bytes is not greater than the maximum unit pool 
size. The process continues to step 335 which determines that unit pool 430 is responsible for 
four byte data sets. In step 340 it is determined that there is an available unit of four bytes in 
chunk 400 of unit pool 430 by locating pointer 409 which is pointing at vacant four byte unit 
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404. The process then goes to step 350 which stores the current four byte data into unit 404 and 
pointer 409 advances to unit 405 indicating that the next piece of four byte data should be stored 
in unit 405. 

5 [0030] As described above, each chunk is a continuous memory area in the system 

memory 1 10. Thus, 32 byte chunk 400 is allocated 32 continuous bytes of system memory 110 
and each of the units 401-408 associated with chunk 400 are continuous within chunk 400. For 
example, unit 401 may occupy bytes 1-4 of chunk 400, unit 402 may occupy bytes 5-8 of chunk 
400, and so on, until all 32 continuous bytes are accounted for by units. Therefore, when data is 

10 stored in a particular unit the pointer information is given to processor 120 and when processor 
120 wants to retrieve the data, processor 120 only needs to refer to the pointer, without any 
additional information. Processor 120 does not need to know the size of the data because the 
mere fact that the pointer is directing processor 120 to a four byte unit pool indicates that the data 
is four bytes. Additionally, there is no need to set a bit in the data that signifies that it is in the 

15 last byte of the data because processor 120 will only take a single unit at a time. For example, if 
processor 120 wanted to retrieve the four byte instruction stored in unit 402, the pointer to unit 
402 would be stored by processor 120 when the data was stored in unit 402. The pointer 
information would indicate to processor 120 that unit 402 was a four byte unit starting at a 
particular byte in system memory, e.g., the fifth byte of chunk 400. Processor 120 then accesses 

20 this location and retrieves that byte and the following three bytes to gain access to the entire 

instruction stored in unit 402. If the data was not stored continuously, then a four byte piece of 
data may require four separate pointers to various physical locations in system memory including 
an indication of how to reassemble the bytes. 

25 [0031] Continuing with Fig. 6, it can be seen that all of units 41 1-418 of chunk 410 have 

been filled with eight byte data. Therefore, there is no pointer pointing to any of units 41 1-418 
because they are not available to accept data. Once again, referring back to Fig. 5, and 
considering that it is determined that the piece of data is eight bytes in step 320 and that there are 
defined unit pools capable of storing data of this size in step 325. In step 335 it is determined 
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that unit pool 440 is responsible for eight byte data sets. Proceeding to step 340, if chunk 410 is 
the only current chunk that has memory space allocated for eight byte data, then the process 

would go to step 345 because there are no currently available units to accommodate data with the 
size of eight bytes, indicated by the lack of a pointer to an empty unit in chunk 410. Units 421, 
5 422 and 424-428 of chunk 420 are filled with sixteen byte data. However, unit 423 is vacant and 
pointer 429 is indicating that the next piece of sixteen bit data should be stored in unit 423. The 
vacancy in unit 423 may be caused by processor 120 erasing data from this unit as a result of, for 
example, the closing of a network connection or an application program. Once a unit is vacated, 
it immediately becomes available for another piece of data of the same size. Additionally, all the 

10 units of a chunk pool should be filled before allocating memory space for another chunk pool 
having the same size unit pools. If a first chunk of a unit pool is filled and a second chunk 
becomes part of the same unit pool, and subsequently, a unit of the first chunk is erased, the 
pointer will continue to fill the second chunk to avoid the "ping-pong" effect between the first 
and second chunks. However, when the second chunk is filled the pointer will go back to the 

1 5 first chunk, rather than allocating a new chunk to the unit pool. 

[0032] Fig. 7 shows an exemplary process flow for allocating system memory space to 

chunks according to the present invention. If there are no available units in the appropriate unit 
pool for the data to be stored, and the unit pool requests a chunk fi-om the chunk pool associated 

20 with the unit pool. In step 505 a correlation between the required unit pool size and the 

associated chunk pool size occurs. The process then continues to step 510 to determine whether 
the requested chunk is available. If the chunk is available fi-om the associated chunk pool, then 
control of the chunk is turned over to the unit pool so that the data may be stored in the chunk 
and the process is complete. If, in step 510, the chunk is not available fi*om the associated chunk 

25 pool, the process continues to step 515 to determine if the requested chunk is the maximum 
chunk size. If, in step 515, the requested chunk size is the maximum chunk size the process 
continues to step 520 where there is an allocation of a chunk of the maximum defined size fi:-om 
system memory. For example, referring back to Fig. 3, if the requested chunk pool was the size 
of chunks 191-192 (8,192 bytes), the process would go to step 520 and allocate another 8,192 
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byte chunk from system memory. If, in step 515, the requested chunk size is not the maximum 
chunk pool size the process continues to step 525 where the request moves from the current 
chunk pool to the next highest chunk pool The process then continues to step 530 to determine 
whether there is an existing chunk of the next higher size available. Again referring back to Fig. 
5 3, if the requested chunk was the size of chunks 161-162 (1,024 bytes), step 530 would determine 
whether there were any chunks of the size of chunks 171-172 (2,048 bytes) available. In step 
530, existing chunks means those chunks that already have system memory space allocated to 
them, not merely that the chunks have been defined. Also, in determining the availability of the 
next higher size chunk, this exemplary process considers existing chunks to be available if they 
10 are still under the control of the chunk pool and have not been relinquished to any unit pools. 

[0033] In step 530, if it is determined that there are no available chunks of the next higher 

size, the process loops back to step 515 to determine if the next higher size chunk pool is the 
maximum chunk pool size. If it is, the process continues to step 520 where there is an allocation 

15 of a chunk of the maximum defined size from system memory space. If it is not, the process, 

once again, proceeds to step 525 to ask the next highest chunk pool and continues to step 530 to 
determine whether there is an available existing chunk of the second next higher size. Again 
referring back to Fig. 3 and the example started above with reference to step 530, if the originally 
requested chunk was the size of chunks 161-162 (1,024 bytes), step 530 in the first instance 

20 would determine whether there were any chunks of the size of chunks 171-172 (2,048 bytes) 
available and if not, in the second instance would determine whether there were any chunks of 
the second next higher size of chunks 181-182 (4,096 bytes) available. Thus, it should be seen 
that steps 515, 525 and 530 form a loop that will not be exited until either a chunk of the 
maximum defined size is allocated in step 525 or there is some existing chunk available. 

25 

[00341 If, in step 530, an existing higher size chunk is available, the process continues to 

step 535 to determine whether the chunk of the maximum size (step 520) or available chunk 
(step 530) are the size of the originally requested chunk that was determined in correlation step 
505. If not, the process continues to step 540 where the chunk is split creating two new chunks. 
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This split does not need to be equal, however, those skilled in the art will recognize that having 
chunks that are equally divisible factors of each other, for example, the sizes of the chunks 
described with reference to Fig. 3, lends to an easier manner of splitting the chunks into multiple 
smaller chunks and returns one of the smaller chunks to the lower chunk pool. The process then 
5 loops back to step 535 to determine if the split chunk is of the size of the originally requested 

chunk. The process continues to loop between steps 535 and 540 until a new chunk pool having 
the size of the originally requested chunk pool determined in correlation step 505 is created. The 
process then ends because since the chunk pool has been created, the unit pool of the desired size 
has been created and the data correlating to the size of the unit pool may be stored as described 
10 with reference to Figs. 5-6. 

[0035] Fig. 8 shows an exemplary process for combining unused chunks which is 

essentially a mirror operation to the exemplary process described with respect to Fig. 7. The 
purpose of this exemplary process is to return memory space to the system memory when the 

1 5 memory manager no longer requires the space. As described above, during system operation data 
that is stored in unit pools may no longer be needed and it may be erased from a unit pool. In 
some cases, all the units of a chunk will be empty because of this erasing and there will be 
allocated memory space that is not being used. Therefore, to the extent possible, this memory 
area should be returned to the system memory or reallocated within the memory manager to more 

20 effectively handle the storage of data. In step 605 a unit is returned to a unit pool, which means 
that the data stored in the unit has been erased and the unit is available to store new data. In step, 
610 it is determined whether the returned unit was the last unit of the chunk. If it is not the last 
unit of the chunk, i.e., active data still is being stored in other units of the chunk, the process 
ends. If, the returned unit is the last unit of the chunk, the process continues to step 615 where 

25 the chunk is returned to the chunk pool. 

[0036] The process then continues to step 620 to determine if the newly returned chunk 

has a matching chunk in the chunk pool. The criteria for finding a match includes that the 
chunks are compatible, that is, the combination of the two chunks form a continuous memory 
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space in the system memory of one of the predefined chunk sizes. If there is no match, the 
process ends. If a match is found, the process continues to step 625 where the two matched 
chunks are combined into a larger matched chunk. The process then goes to step 630 where the 
newly combined matched chunk is returned to the next highest chunk pool. The process then 
continues to step 635 where it is determined whether the newly combined matched chunk created 
in step 625 is a chunk of the maximum size. If it is not, the process loops back to step 620 to 
determine whether the newly combined matched chunk has a matching chunk in the higher chunk 
pool and the process continues as was described above. If in step 635, the newly combined 
matched chunk is of the maximum chunk size, the process continues to step 640 where it is 
determined whether the chunk pool has any additional chunks. If there are no additional chunks, 
the process ends to avoid "ping-ponging" with system memory. However, if it is not the only 
chunk in the chunk pool, the process continues to step 645 where a chunk having the maximum 
predefined size is returned to the system memory for its use. 

[0037] In the preceding specification, the present invention has been described with 

reference to specific exemplary embodiments thereof It will, however, be evident that various 
modifications and changes may be made thereunto without departing from the broadest spirit and 
scope of the present invention as set forth in the claims that follow. The specification and 
drawings are accordingly to be regarded in an illustrative rather than restrictive sense. 
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